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As  the  Department  of  Defense  (DoD)  continues  to  transform  into  a  more  efficient  and 
coordinated  fighting  force,  the  elements  of  logistics  support  will  continue  to  become  more 
complex  and  will  require  more  efficient  ways  of  communication.  The  component  Services 
currently  have  a  myriad  of  logistics  systems  available  to  support  their  individual  Service 
members.  Many  of  these  systems  are  not  interoperable  even  within  the  same  Service.  The 
DoD  has  initiated  the  development  of  the  Global  Combat  Support  System  (GCSS)  to  expand 
logistical  information  to  operational  levels.  In  recent  years,  private  industry  has  been  using  the 
extensible  Mark-up  Language  (XML)  to  promote  interoperability  among  related  industry 
partners  via  common  or  standard  XML  based  data  exchanges.  The  Defense  Information 
Systems  Agency  (DISA)  has  also  recently  stood  up  the  XML  registry  for  the  Defense 
Information  Infrastructure  (Dll)  Common  Operating  Environment  (COE).  The  development  of 
this  registry  provides  a  platform  for  enabling  the  standardization  of  DoD  logistics  data  elements. 
If  the  DoD  could  develop  a  standard  XML  based  data  exchange  for  logistics  support,  all  of  those 
systems  that  are  currently  in  use  could  be  mapped  to  the  new  standard  exchange  to  provide  an 
exchange  of  information  between  computer  systems  that  currently  do  not  have  that  capability. 
The  standard  logistics  data  definitions  within  GCSS  could  be  used  as  a  starting  point  to 
augment  existing  data  element  definitions  in  the  DISA  XML  registry.  By  cross-referencing  and 
augmenting  the  existing  logistics  data  definitions  in  the  DISA  XML  registry  with  the  standard 
definitions  within  GCSS,  the  DoD  could  begin  to  manage  the  myriad  of  logistics  data  definitions 
and  move  forward  in  developing  a  standard  joint  logistics  data  exchange.  This  paper  will 
explore  the  previous  attempts  to  standardize  DoD  logistics  data  and  the  possibility  of  developing 
a  standard  XML  based  data  exchange  for  Joint  Logistics  Information,  the  problems  associated 
with  this  process  and  what  the  subsequent  benefits  will  be. 
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PREFACE 


For  want  of  a  nail,  the  shoe  was  lost; 

For  want  of  the  shoe,  the  horse  was  lost; 

For  want  of  the  horse,  the  rider  was  lost; 

For  want  of  the  rider,  the  battle  was  lost; 

For  want  of  the  battle,  the  kingdom  was  lost. 

And  all  for  the  want  of  a  nail. 

—  Author  Unknown 

Many  people  within  the  Department  of  Defense  (DoD)  logistics  data  management 
community  have  long  realized  the  need  to  be  able  to  exchange  information  between  various 
logistics  support  functions.  The  DoD  logistics  support  processes  allow  the  United  States 
component  Services  to  keep  US  forces  maintained  in  a  high  state  of  readiness  throughout  the 
world.  As  the  DoD  logistics  information  systems  become  more  integrated  and  able  to  share 
information  more  readily,  they  will  help  improve  the  readiness  of  combined  forces  while  reducing 
the  costs  associated  with  maintaining  readiness. 

Historically,  the  DoD  has  not  been  very  good  at  integrating  information  either  within 
individual  Services  or  between  the  four  Services.  During  Operation  Desert  Shield/Desert  Storm, 
the  logistics  philosophy  was  to  mass  as  much  supply  and  repair  materials  as  possible  within  the 
area  of  operations  in  order  to  maintain  the  fighting  forces  in  Saudi  Arabia.  The  speed  and 
operational  tempo  envisioned  for  future  combat  systems  of  tomorrow  will  not  afford  future 
logistics  systems  the  luxury  of  having  large  amounts  of  time  to  mass  the  materials  that  might  be 
needed  to  sustain  battlefield  operations.  The  future  logistics  processes  will  need  to  work 
smarter  and  faster  with  much  less  mass  and  higher  velocities  of  material-flow  in  order  to  have 
the  right  material  at  the  right  place  and  at  the  right  time. 

In  recent  years,  improvements  in  the  ways  computer  systems  share  information  have 
allowed  the  Services  to  collect  more  accurate  and  timely  data  concerning  asset  availability, 
repair  status,  in-transit  visibility  and  delivery  status.  Much  more  needs  to  be  done  to  allow  the 
Services  to  assimilate  and  transform  this  data  into  knowledge  that  can  be  used  to  make  sure 
that  deployed  combatant  forces  receive  the  best  support  available  through  combined  logistics 
support  processes.  Fighting  forces  of  the  United  States  should  never  be  put  in  the  position  of 
facing  defeat  for  want  or  need  of  logistical  support. 
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INTEROPERABILITY  AND  A  STANDARD  JOINT  LOGISTICS  DATA  EXCHANGE  WITHIN  THE 

DEPARTMENT  OF  DEFENSE 


The  description  of  “Focused  Logistics”  that  the  Joint  Staff  has  provided  in  Joint  Vision 
2020  is  “the  ability  to  provide  the  joint  force  the  right  personnel,  equipment  and  supplies  in  the 
right  place,  at  the  right  time  and  in  the  right  quantity,  across  the  full  range  of  military 
operations.”^  This  vision  provides  a  starting  point  for  the  Department  of  Defense  (DoD) 
logisticians  to  develop  capabilities  that  will  enable  this  vision  to  become  a  reality.  The  ability  to 
deliver  a  transformed  logistics  process  based  on  this  vision  is  in  part  determined  by  the 
technology  available  to  gather,  assimilate  and  categorize  the  data,  identify  the  context  in  which 
it  must  be  used  and  transform  this  data  into  knowledge  that  logisticians  at  both  strategic  and 
operational  levels  can  use.  Advances  in  Internet  technology,  such  as  the  development  of 
business  process  data  exchanges  can  be  leveraged  to  enable  the  knowledge  transformation 
processes  within  the  DoD. 

Business  process  data  exchanges  are  currently  being  used  throughout  private  industry  to 
enable  the  sharing  of  information  between  business  partners.  The  standard  logistics  data 
definitions  within  the  Global  Combat  Support  System  (GCSS)  could  be  used  as  a  starting  point 
to  augment  existing  data  element  definitions.  By  cross-referencing  and  augmenting  the  existing 
logistics  data  definitions  in  a  DoD  registry  with  the  standard  definitions  within  GCSS,  the  DoD 
could  begin  to  manage  the  myriad  of  logistics  data  definitions  and  move  forward  in  developing  a 
standard  joint  logistics  data  exchange.  This  paper  will  explore  the  previous  attempts  to 
standardize  DoD  logistics  data,  the  possibility  of  developing  a  standard  extensible  Mark-up 
Language  (XML)  based  data  exchange  for  Joint  Logistics  Information,  the  problems  associated 
with  this  process  and  the  subsequent  benefits  of  a  logistics  data  exchange. 

Under  direction  of  the  Deputy  Under  Secretary  of  Defense  for  Logistics  and  Materiel 
Readiness  DUSD(LM&R),  the  Joint  Logistics  Board  (JLB)  developed  a  white-paper  that 
highlighted  six  integrated  and  collaborative  initiatives  as  elements  of  a  document  entitled  the 
Future  Logistics  Enterprise  (FLE).  These  initiatives  were  intended  to  identify  ways  to  accelerate 
DoD’s  implementation  of  integrated  logistics.  The  sixth  initiative  of  the  FLE  document  is 
Enterprise  Integration  (El).  Identifying  common  functions  between  the  Services  allows  the  El 
initiative  to  reuse  specific  business  process  software  modules.  The  reuse  of  common  business 
processes  could  help  avoid  additional  software  and  interface  changes  between  the  Services’ 
automated  logistics  systems.  The  JLB  “estimates  that  between  $1 .5B  and  $2.5B  is  spent 
annually  to  support  thousands  of  logistics  systems  and  their  associated  interfaces  across  the 


DoD.”^  It  is  no  longer  feasible  for  the  DoD  to  continue  maintaining  this  myriad  of  system 
interfaces  at  very  high  costs.  It  is  the  intent  of  the  El  initiative  to  provide  logisticians  access  to 
“actionable  information  provided  by  modern,  commercially-based  software  products  that  have 
been  rapidly  implemented  to  reengineered  logistics  processes  and  business  rules.’^ 

The  development  of  a  standardized  DoD  logistics  data  exchange  would  allow  the  military 
Services  to  reengineer  their  logistics  processes  and  business  rules  in  increments.  Most 
successful  reengineering  processes  are  completed  in  small  manageable  increments  or 
continuous  cycles  of  improvement  via  pilot  programs.  In  1996  a  U.S.  General  Accounting  office 
report  on  reengineering  the  Air  Force’s  logistics  system  reported  that  “using  the  pilot  program 
approach  shortens  the  implementation  time,’”*  resulting  in  more  efficient  processes.  More 
efficient  processes  coupled  with  cultural  change  and  continuous  improvements  can  stimulate 
further  reductions  in  logistics  inventories,  resulting  in  greater  cost  savings. 

As  the  DoD  works  to  accelerate  the  implementation  of  integrated  logistics  through  the  six 
collaborative  initiatives,  the  individual  Services  must  identify  any  obstacles  that  must  be 
overcome  to  achieve  this  goal.  “The  corporate  culture  within  DoD  ...  has  been  traditionally 
resistant  to  change  and  must  become  receptive  to  radical  new  concepts  of  operations.’’®  In 
addition  to  the  issues  associated  with  the  six  collaborative  initiatives  identified  by  DUSD(LM&R), 
there  are  many  other  roadblocks  that  can  keep  the  vision  of  Focused  Logistics  from  happening. 
History  shows  that  the  DoD  has  been  wrestling  with  the  problems  of  systems  interoperability 
and  data  standards  for  many  years. 

BACKGROUND  ON  DOD  LOGISTICS  STANDARDIZATION  PROCESSES 

Logisticians  across  DoD’s  component  Services  must  be  able  to  share  information  at  all 
levels  of  command.  Not  only  must  information  be  available  for  sharing,  but  it  also  must  be 
actionable  data  that  can  be  used  to  solve  problems  such  as  moving  material,  locating  spare 
parts,  identifying  critical  repair  information  or  processes  and  accurately  predicting  equipment 
failures.  From  one  Service  to  the  next  the  data  to  support  logistics  processes  is  often  defined 
differently  both  in  terms  of  the  context  and  data  fields  used  to  describe  the  information  being 
processed.  The  ideal  scenario  to  promote  interoperability  among  DoD’s  Service  specific 
systems  would  be  for  all  Services  to  adhere  to  a  standard  set  of  data  definitions  for  all  of  their 
logistics  processes.  The  DoD  has  sponsored  many  efforts  to  standardize  logistics  data.  Many 
of  the  products  that  resulted  from  DoD  standardization  efforts  could  be  used  in  the  development 
of  an  XML  based  data  exchange  for  joint  logistics  information  processes. 
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MILS  AND  DLSS 

As  the  DoD  began  automating  its  logistics  systems  in  the  early  1960s,  logistics  leaders 
realized  that  they  would  need  to  identify  standard  transactions  for  various  transaction 
processes.  Through  the  efforts  of  the  Defense  Logistics  Management  Standards  Office 
(DLMSO)  the  DoD  began  to  develop  interoperability  standards  via  the  “Military  Standard 
Logistics  Systems  (MILS)”®  transactions  to  move  logistics  data  through  the  Defense  Logistics 
Standard  System  (DLSS).  This  enabled  the  automated  movement  of  information  from  one 
Military  Service  system  to  another.  The  standard  MILS  transactions  were  based  upon  the 
standard  input  media  of  the  day,  the  eighty-character  punched  card.  The  punched  cards 
provided  eighty  characters  to  identify  the  transaction  type  and  all  of  the  associated  information 
that  needed  to  be  processed  with  that  transaction. 

Examples  of  the  many  types  of  eighty  character  transaction  sets  are  the  “Military  Standard 
Requisitioning  and  Issue  Procedures  (MILSTRIP),  Military  Standard  Transaction  Reporting  and 
Accounting  Procedures  (MILSTRAP),  Military  Supply  and  Transportation  Evaluation  Procedures 
(MILSTEP)  and  Military  Standard  Billing  System  (MILSBILLS).”^  These  standard  transaction 
types  were  used  to  allow  the  different  Services  to  exchange  information  with  each  other  and 
DLA.  The  eighty-character  card  MILS  transactions  served  the  DoD  well  throughout  the  70s  and 
into  the  80s.  However,  the  format  limit  of  eighty  characters  per  card  made  it  difficult  to  expand 
the  amount  of  information  and  capabilities  of  the  systems  using  them.  The  Defense  Logistics 
Agency’s  (DLA’s)  Defense  Automated  Addressing  System  Center  (DAASC)  was  processing 
MILS  transactions  at  a  rate  of  several  hundred  million  transactions  a  year  and  currently 
“approximately  one  billion  transactions  are  transmitted  annually.”®  The  DAASC  managed  the 
processing  of  MILS  transactions  and  began  efforts  to  expand  the  size  of  the  MILS  transactions 
in  order  to  take  advantage  of  advances  in  information  technology  development  efforts. 

DEN  DICTIONARY 

In  addition  to  developing  standard  transaction  formats  the  DLMSO  also  began  working 
with  military  Service  representatives  to  standardize  data  elements  to  be  used  in  the  standard 
MILS  transactions.  A  data  element  identifies  attributes  that  are  either  an  input  or  output  of  an 
automated  process.  The  data  element  description  identifies  how  the  data  is  used,  the  number 
of  characters  used  to  describe  the  data  and  any  restrictions  on  its  use,  i.e.  numeric,  alpha  or 
combinations  thereof.  Standard  data  element  names  (DENs)  were  assigned  to  each  data 
element  and  the  data  elements  along  with  their  assigned  DEN  numbers  and  descriptions  were 
coordinated  with  each  Service  and  recorded  in  the  Standard  DEN  Dictionary.  The  DoD 


3 


developed  standard  MILS  transactions  containing  DEN  information  for  financial,  item  cataloging, 
requisitioning,  procurement,  repair,  contracting  and  asset  reporting  processes. 

DEFENSE  AUTOMATED  ADDRESSING  SYSTEM  CENTER 

The  DAASC  has  developed  standard  automated  cross  reference  interpreters  for  MILS, 
Electronic  Data  Interchange  (EDI)  and  XML  based  transactions  to  enhance  DoD  logistics 
processes.  The  DAASC  has  automated  standard  transaction  reference  tables  built  into  their 
transaction  process.  The  tables  enable  the  DAASC  system  to  process  MILS,  EDI  and  XML 
transactions  interchangeably.  Soon  after  the  Defense  Logistics  Agency  was  tasked  to 
consolidate  wholesale  logistics  processes  for  all  DoD  consumable  items,  it  was  recognized  that 
the  DoD  also  needed  to  expand  the  amount  of  data  that  could  be  transmitted  by  the  MILS 
transaction  sets.  “DRID#48  established  a  DoD  EDI  integrated  product  team  and  directed  all 
DoD  logistics  components  to  begin  adopting  commercial  EDI  standards.’®  The  DoD  began 
working  with  industry  partners  to  develop  variable  length  electronic  data  interchange  (EDI) 
transactions  for  the  various  logistics  processes.  DAASC  then  incorporated  these  EDI 
transactions  into  its  system  processes  and  automatically  performed  conversions  between  the 
EDI  and  MILS  transactions. 

EDI  STANDARDS 

Electronic  Data  Interchange  (EDI)  was  established  as  a  technology  for  processing 
computer-based  transactions  between  two  business  partners.  The  EDI  standards  development 
process  was  very  similar  to  the  development  of  the  DoD  MILS  standards  except  that  this  effort 
recognized  the  need  to  expand  beyond  the  eighty  character  restrictions  imposed  by  the 
punched  cards  used  for  MILS.  The  efforts  of  commercial  standards  organizations  to  develop 
standards  for  electronic  commerce  and  electronic  data  interchange,  such  as  the  United  Nations 
Electronic  Data  Interchange  for  Administration,  Commerce  and  Transport  (UN/EDIFACT) 
standards,  continue  to  aid  the  exchange  of  data  within  commercial  industries.  Usually  the 
standards  developed  do  not  cover  all  aspects  of  data  that  are  required  to  be  shared  within  the 
DoD  logistics  support  processes.  EDI  transaction  processing  was  not  well  received  by  some  of 
DoD’s  small  commercial  vendors  because  of  the  high  cost  of  implementing  EDI  transaction 
processes.  “Implementing  traditional  EDI  requires  a  significant  investment  of  time  and  money 
for  developing  and  maintaining  agreed-upon  inter-  and  intra-industry  standards  and  trading- 
partner-specific  implementing  conventions  for  those  generic  standards.”^®  The  DoD  processes 
could  be  realigned  to  make  use  of  all  EDI  transactions  that  currently  exist.  Flowever,  there  are 
some  unique  operational  support  processes  within  DoD  that  must  be  accommodated  within  the 
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EDI  transactions,  or  the  DoD  will  need  to  supplement  the  existing  transaction  sets  with  uniquely 
DoD  transactions. 

CIM  AND  THE  JOINT  LOGISTICS  SYSTEMS  CENTER 

The  DoD  Corporate  Information  Management  (CIM)  initiative  goals  were  to  improve  the 
standardization,  quality  and  consistency  of  data  from  DoD’s  many  information  management 
systems  and  to  reduce  the  duplicative  functional  systems  across  the  DoD.  The  CIM  effort  for 
logistics  processes  began  reviewing  existing  DoD  logistics  systems  in  order  to  identify  the  best 
systems  to  be  used  as  standardized  processes  across  all  DoD  military  Services.  The  DoD  Joint 
Logistics  Systems  Center  (JLSC)  was  stood  up  to  manage  the  DoD  Logistics  CIM  efforts.  As 
part  of  the  standard  systems  development  efforts  at  the  JLSC,  all  of  the  military  Services 
participated  in  an  effort  to  identify  all  data  and  processes  associated  with  the  logistics  processes 
of  materiel  management  and  depot  maintenance.  “Created  as  a  showcase  for  DoD’s  Corporate 
Information  Management  initiative,  JLSC  was  supposed  to  replace  hundreds  of  legacy  systems 
used  by  the  Services  with  a  single  family  of  standard  applications.’’^^  Although  many  of  the 
standard  systems  developed  at  the  JLSC  were  never  fully  implemented  across  all  of  DoD,  some 
systems  were  successfully  implemented  and  the  standard  data  and  process  models  developed 
during  that  timeframe  have  been  used  successfully  to  identify  common  data  and  processes 
across  the  DoD  military  Services. 

CALS  STANDARDS 

The  Computer-aided  Acquisition  and  Logistics  Support  (CALS)  initiative  developed 
standards  for  data  exchange  and  supported  many  initiatives  for  paperless  processing  of 
business  transactions.  The  CALS  efforts  encouraged  DoD  project  managers  and  procurement 
personnel  to  begin  buying  digital  data  rather  than  hard  copy  engineering  drawings  and  technical 
manuals  in  support  of  new  weapon  systems.  The  DoD  CALS  program  offices  also  tackled  the 
difficult  task  of  digitizing  the  millions  of  existing  engineering  drawings  and  technical  manuals  into 
standard  formats  that  could  be  used  for  repair  support  and  re-procurement  efforts.  DoD 
suppliers  were  affected  by  CALS  standards  imposed  for  processing  engineering  and  technical 
data.  Some  of  those  effects  were  positive  since  the  standards  imposed  were  also  adopted  by 
private  industry  and  could  be  used  for  other  industry  processes. 

CALS  addressed  issues  with  the  timely  and  efficient  handling  of  information  that 
supported  weapons  and  commercial  products  acquired  by  the  DoD.  The  whole  idea  of  CALS 
was  to  improve  productivity  within  DoD  as  well  as  reduce  the  paperwork  required  from 
supporting  vendors  and  suppliers.  The  CALS  efforts  developed  methods  and  standards  for 
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electronic  transmission  of  engineering  drawings,  technical  manuals  and  manufacturing 
documentation.  Many  logisticians  realized  that  the  standards  they  were  establishing  for  logistics 
processes  needed  to  be  adopted  by  the  acquisition  world  so  that  any  electronic  media  that  was 
purchased  in  support  of  major  weapon  systems  would  be  compatible  with  the  logistics 
processes.  The  concept  of  CALS  migrated  to  the  Continuous  Acquisition  and  Life-Cycle 
Support/Electronic  Data  Interchange  (CALS/EDI)  concept  that  allowed  standards  proponents  to 
work  more  closely  with  acquisition  offices  to  standardize  technical  support  data  required  for 
acquisition  transactions  and  life  cycle  support  of  weapon  systems. 

THE  DEFENSE  REFORM  INITIATIVE  DIRECTIVE  (DRID)  #54  AND  LOGISTICS 
TRANSFORMATION 

Although  the  DoD  has  expended  vast  resources  for  the  purpose  of  standardizing  logistics 
data  and  its  processes,  there  currently  exist  many  logistics  systems  and  processes  that  do  not 
use  standard  data  or  processes.  DRID  #54  recognized  the  need  to  transform  DoD  logistics 
processes  so  that  they  could  be  made  more  interoperable  and  react  with  greater  precision  and 
reliability.  “The  DRID  #54  required  the  military  Services,  TRANSCOM,  and  the  Defense 
Logistics  Agency  (DLA)  to  submit  logistics  transformation  implementation  plans  to  be  reviewed 
for  consistency  with  the  DoD  Logistics  Strategic  Plan  objectives  and  Joint  Staff’s  Joint  Vision 
2010.”'^ 

Future  logistics  systems  will  be  built  in  part  by  reengineering  legacy  systems  that  will  be 
required  to  operate  in  a  network  centric,  information  centric  and  real-time  web-based 
environment.  Traditional  logistics  business  processes  will  need  to  change.  As  a  result  of  this 
focus,  the  Joint  Chiefs  of  Staff,  Director  for  Logistics  (J-4)  and  the  Deputy  under  Secretary  of 
Defense  (Logistics)  have  partnered  with  the  Services,  Combatant  Commanders  and  the 
Defense  Agencies  to  begin  establishing  this  new  environment.  Figure  1  outlines  the  DRID  #54 
goals  of  the  23  March  2000  “Logistics  Transformation  Plans.” 
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FIGURE  1:  LOGISTICS  TRANSFORMATION 


Based  on  the  goals  of  the  DRID  #54,  the  DoD  has  developed  requirements  for  a  Global 
Combat  Support  System  (GCSS).  DoD  has  also  assembled  background  information  for 
ongoing  logistics  improvement  efforts,  prepared  initial  design  characteristics,  prepared  business 
process  constructs  by  commodity  class,  coordinated  preliminary  design  across  all  DoD 
stakeholders  and  begun  holding  technical  interchange  meetings  between  all  of  the  Military 
Services,  DLA,  Combatant  Commanders  and  Industry  representatives. 

GCSS  DEVELOPMENT 

The  goal  of  the  Global  Combat  Support  System  is  to  integrate  logistics  information  across 
all  logistics  functional  areas,  combat  support  processes  and  the  command  and  control  (C2) 
processes  to  provide  universal  access  to  specific  users  of  logistics  information.  Access  is 
restricted  to  “need-to-know.”  Since  its  primary  purpose  is  to  provide  operational  support  to  the 
war-fighter,  GCSS  will  not  process  information  in  support  of  the  various  logistics  processes, 
rather  it  will  require  access  to  the  data  that  all  DoD  logistics  processes  produce.  The  logistics 
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support  functional  areas  include  “transportation,  supply,  maintenance,  personnel,  force/health 
protection,  acquisition,  finance  and  engineering.”  The  scope  of  requirements  for  GCSS  is 
focused  on  information  interoperability  between  the  DoD  military  “Services,  Defense  Agencies, 
commercial  sector  vendors,  U.S.  government  agencies  and  non-governmental  organizations 
(NGOs).”^^ 

The  six  essential  attributes  of  GCSS  are:  “1)  any  box,  2)  any  user,  3)  one  net,  4)  one 
picture,  5)  common  services,  and  6)  a  robust  communications  infrastructure.”^®  “Any  box” 
refers  to  the  ability  to  access  information  via  any  computer  system,  while  “any  user”  refers  to 
allowing  access  to  all  users  across  the  area  of  operations.  “One  net”  refers  to  the  global 
command  and  control  structure  that  is  to  be  available  across  the  area  of  operations  and  all 
logistics  support  functional  areas.  “One  picture”  requires  that  the  same  information  be 
presented  to  all  users  in  the  same  format  so  that  all  users  will  have  the  same  look  and  feel. 
“Common  services”  are  those  basic  computer  services  such  as  communication  access  across 
networks  and  printer  services.  “A  robust  communications  infrastructure”  will  be  required  to 
alleviate  communications  bottlenecks  and  improve  the  efficiency  with  which  data  is  processed 
from  one  node  in  a  network  to  another. 

COMPLEXITIES  OF  INTEGRATING  NEW  LOGISTICS  SYSTEMS 

As  the  DoD  begins  using  commercially  available  software  packages  in  attempts  to  cut 
systems  development  efforts,  it  compounds  the  issues  involved  with  standard  data  by 
introducing  additional  data  elements  with  different  data  definitions.  In  addition  to  the  differences 
in  data  definitions,  the  DoD  must  also  deal  with  interface  issues  with  various  systems 
processing  logistics  data.  Application  program  interfaces  (APIs)  allow  different  application 
programs  and  or  computer  systems  to  exchange  information.  Figure  2  Illustrates  the  complexity 
of  building  APIs  between  disparate  computer  systems  using  different  definitions  for  the  data 
being  exchanged. 
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FIGURE  2:  APPLICATION  PROGRAM  INTERFACES  (API) 


Every  new  application  program  or  package  that  is  introduced  to  operate  with  existing 
applications  must  have  additional  interfaces  built  to  accommodate  interoperability  with  the 
existing  systems.  Application  program  interfaces  (APIs),  map  the  data  from  one  system  to 
another  so  that  the  two  systems  for  which  an  interface  is  developed  can  exchange  data  in  the 
correct  format.  A  new  API  must  be  built  for  each  system  that  needs  to  exchange  data  with  any 
new  application  that  will  operate  within  the  systems  architecture  supporting  the  logistics 
functions  within  the  DoD.  Additionally,  if  one  of  the  existing  systems  changes,  new  APIs  must 
be  developed  to  accommodate  the  changes  between  the  systems.  The  constant  API 
development  process  between  changing  computer  systems  helps  to  account  for  some  of  the 
“$1 .5B  and  $2.5B  that  is  spent  annually  to  support  thousands  of  logistics  systems  and  their 
associated  interfaces.”^^ 

Section  816  of  the  National  Defense  Authorization  Act  for  Fiscal  Year  1999  required  the 
“Secretary  of  Defense,  acting  through  the  Secretaries  of  the  military  departments,  to  designate 
10  weapon  system  programs  to  test  program  manager  performance  of  product  support 
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oversight  responsibilities  for  life  cycle  support  of  acquisition  programs.”^®  This  means  that  the 
contractor  who  is  responsible  for  building  a  weapon  system  will  now  be  given  the  responsibility 
to  maintain  that  weapon  system  throughout  its  lifecycle.  The  contractor  and  the  program 
manager  for  the  weapon  system  will  need  access  to  existing  legacy  logistics  systems  in  order  to 
take  advantage  of  existing  standard  parts  that  may  be  used  within  the  development  of  the 
weapon  system. 

With  the  DoD  program  offices  moving  to  contract  out  life  cycle  management  of  the 
weapon  systems  they  are  procuring,  interfaces  to  even  more  applications  and  systems  will  be 
required  to  maintain  a  high  level  of  information  sharing.  DoD  logisticians  will  need  to  identify 
ways  to  make  contractor  life  cycle  support  systems  interoperable  with  new  supply  chain  and 
existing  DoD  logistics  systems.  The  use  of  a  standard  XML  based  data  exchange  for  joint 
logistics  information  would  enable  the  required  exchanges  of  information  and  product 
development  collaboration  between  government  procurement  offices  and  their  respective 
contractors. 

DEVELOPMENT  CONSISTENT  WITH  JV2020 

Joint  Vision  2020  identifies  information  superiority  and  innovation  as  major  tenets  of  full 
spectrum  dominance.  Information  superiority  allows  a  fighting  force  to  achieve  knowledge 
superiority,  which  in  turn  fosters  decision  superiority.  Additionally  the  Joint  Chiefs  of  Staff 
identify  “innovation  as  a  vital  component  of  the  transformation  of  the  joint  force.”’®  The 
development  of  a  DoD  wide  data  exchange  for  logistics  data  would  provide  innovative  avenues 
of  interoperability  to  all  DoD  logistics  systems  that  are  not  currently  available  through  existing 
processes. 

The  GCSS  being  developed  to  provide  operational  support  to  the  war-fighter  could  benefit 
from  the  enhanced  interoperability  that  a  common  data  exchange  would  provide,  since  the 
exchange  would  furnish  a  common  set  of  data  definitions  and  the  context  for  using  the 
information.  Enhanced  interoperability  leads  to  information  superiority.  The  information 
provided  by  XML  based  data  exchanges  are  commonly  referred  to  as  intelligent  data,  since  all 
of  the  information  about  the  context,  use  and  format  are  transmitted  with  the  data.  Intelligent 
data  enhances  interoperability  between  computer  systems.  JV2020  highlights  interoperability 
as  the  foundation  for  effective  joint  operations.  Within  the  logistics  community  the  DoD  could 
achieve  information  superiority  by  providing  a  greater  degree  of  interoperability  among  the 
various  existing  logistics  processes.  Simultaneously,  the  DoD  could  also  improve  the  ability  to 
integrate  new  enterprise  resource  planning  (ERP)  systems  with  existing  legacy  architectures. 
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ENTERPRISE  RESOURCE  PLANNING  (ERP) 

Most  of  the  Military  Services  are  currently  involved  in  the  implementation  of  major  ERP 
systems  which  will  replace  parts  of  their  aging  legacy  supply  chain  management  processes. 

ERP  systems  can  integrate  many  functions  across  a  Service’s  supply  chain  management 
process,  including  the  requirements  of  finance,  human  resources,  acquisition,  warehousing  and 
shipping.  The  ERP  system  replaces  many  of  the  individual  computer  applications  and 
databases  within  the  organization  with  a  single  system  that  enhances  the  overall  performance  of 
the  organization’s  order  fulfillment  processes.  Although  most  of  the  military  Services  will  be 
using  ERP  solutions  to  replace  a  majority  of  the  existing  legacy  supply  chain  systems,  there  will 
continue  to  be  many  existing  logistics  systems  that  the  Services  will  need  to  maintain  and 
interface  with  the  new  ERP  systems. 

Information  superiority  can  be  achieved  when  data  from  uniquely  DoD  and  existing  legacy 
supply  chain  systems  exchange  smoothly  with  newly  installed  ERP  systems.  This  information 
superiority  could  be  achieved  with  relatively  low  cost  and  the  data  exchange  could  leverage 
existing  logistics  standardization  processes  while  providing  less  costly  ways  to  integrate  new 
technologies  being  fielded  via  the  ERP  systems  development  processes.  A  data  exchange 
could  blend  new  technological  innovation  and  conceptual  innovation  into  an  imaginative 
recombination  of  old  data  standards  with  new  computer-based  processes  to  enhance  DoD 
supply  chain  management  processes. 

USING  XML  FOR  AN  OPEN  DATA  EXCHANGE 

Since  the  debut  of  the  extensible  Markup  Language  (XML)  as  an  open  data  exchange 
language  in  1998,  it  has  been  possible  to  allow  manufacturers  to  exchange  business 
information  and  define  business  processes  that  are  independent  of  application  program 
interfaces.  XML  enables  different  computer  systems  to  exchange,  interpret  and  act  on  data 
even  when  computer  systems  run  on  different  hardware  and  are  using  different  programming 
languages.  In  addition  to  the  interoperability  between  two  or  more  disparate  computer  systems, 
XML  based  data  can  be  presented  in  a  traditional  Web  page  format.  Any  user  who  has  been 
given  access  to  the  exchange  and  who  has  access  to  the  Internet  or  Intranet  through  a  standard 
personal  computer  and  browser  such  as  Navigator  or  Explorer  can  view  and  process  the 
information  being  passed  through  the  exchange. 

The  key  to  developing  a  successful  XML  based  data  exchange  is  the  development  of 
standard  definitions  for  the  data  being  represented.  Data  standards  are  difficult  to  develop  and 
are  even  more  difficult  to  agree  upon.  The  many  different  entities  involved  in  doing  business 
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with  each  other  all  have  their  own  idea  of  what  data  standards  should  be  used  to  do  business. 
The  benefit  of  using  XML  is  that  the  trading  partners  need  only  define  one  set  of  XML  based 
data  standards  that  represents  the  data  that  they  want  to  use  to  do  business  with  each  other. 
The  structure  for  describing  data  elements  within  XML  is  Document  Type  Definitions  (DTDs).  It 
is  possible  to  further  define  DTDs  with  XML  schemas. 

The  definitions  executed  in  schemas  can  describe  data  types  and  the  relations  between 
data  types.  Because  XML  is  extensible,  new  components  can  be  added  to  existing  schemas 
without  affecting  the  existing  computer  system  interfaces  using  the  schema.  System  developers 
would  have  the  option  to  incrementally  change  their  existing  systems  to  take  advantage  of  any 
new  components  added  to  the  data  exchange.  It  is  because  of  the  XML  schema  definition 
flexibility  that  XML  schemas  have  become  an  important  tool  for  describing  information  structures 
of  any  kind.  XML  DTDs  and  XML  schemas  that  represent  a  specific  data  structure  for  a  specific 
business  process  or  function  can  be  “registered  as  XML  specifications  with  the  World  Wide  Web 
Consortium  (W3C)  or  registered  with  the  XML.org  registry.”  When  a  schema  is  registered  in  a 
public  domain  such  as  W3C  and  XML  registry,  it  allows  that  structure  to  be  used  by  other 
developers,  who  can  then  provide  additional  processes  and  services  decreasing  the  costs 
associated  with  managing  the  information. 

XML  registries  are  available  as  a  world  wide  central  clearing  house  to  allow  developers 
and  standards  bodies  to  publicly  submit,  publish  and  exchange  XML  schemas,  vocabularies  and 
related  documents.  When  a  universe  of  data  has  been  identified  and  the  trading  partners  have 
agreed  to  the  standard  definitions,  they  must  map  their  existing  systems  to  an  XML  data 
exchange  in  order  to  provide  interoperability.  If  a  new  trading  partner  wants  to  use  this 
exchange,  this  new  partner  need  only  map  their  data  and  processes  to  the  existing  data 
exchange  to  be  able  to  begin  processing  transactions  with  the  other  partners. 

The  extensibility  of  XML  allows  the  addition  of  more  data  definitions  to  the  existing  data 
exchange.  Any  trading  partner  can  take  advantage  of  the  new  data  definitions  by  making 
appropriate  changes  to  their  existing  computer  systems  to  use  the  additional  data.  The 
advantage  of  using  this  type  of  process  rather  than  APIs  is  that  no  partner  needs  to  change  their 
current  system  processing  or  existing  exchange  mapping  process  when  additional  data  is  added 
to  the  data  exchange.  Figure  3  illustrates  how  a  standard  XML  data  exchange  simplifies  the 
interfaces  between  many  disparate  computer  systems. 
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FIGURE  3:  THE  STANDARD  XML  DATA  EXCHANGE 


Only  those  partners  who  have  a  need  for  the  additional  information  being  offered  and  the 
means  to  change  their  existing  systems  processes  need  to  make  changes.  The  DoD  Defense 
Information  Systems  Agency  (DISA)  has  recently  stood  up  the  XML  registry  for  the  Defense 
Information  Infrastructure  (Dll)  Common  Operating  Environment  (COE).  The  development  of 
this  registry  provides  a  platform  for  enabling  the  standardization  of  DoD  logistics  data  elements 
among  the  various  military  Services. 

DISA’S  XML  REGISTRY 

An  XML  registry  is  an  important  component  of  any  online  data  exchange.  The  DISA 
registry  provides  support  to  system  developers  and  integrators  by  establishing  common  lexicons 
and  grammars  for  various  functions  within  the  DoD  logistics  processes  and  the  DoD  Common 
Operating  Environment  (COE).  This  registry  enables  the  consistent  use  and  reuse  of  XML 
based  DTDs  and  schemas  and  contributes  to  the  interoperability  of  those  systems  making  use 
of  the  registry.^^  The  registry  provides  a  platform  to  allow  DoD  integration  organizations  to 
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search  for  existing  XML  data  components  and  coordinate  the  development  of  new  common 
XML  data  components. 

Another  element  of  service  often  provided  by  a  data  exchange  is  common  data  access 
services.  Common  data  access  services  build  XML  based  architectures  to  bridge  between 
different  data  sources.  A  system  “architecture  can  improve  data  sharing  within  the  DoD  COE 
and  between  the  COE  and  non-COE  systems.’^^  DISA  is  currently  developing  a  “common 
exchange  table  architecture,  known  as  ‘Garlic  Fries’,  planned  for  incorporation  in  the  4.X  series 
COE  software. This  common  architecture  should  improve  access  to  the  common  data 
structures,  within  the  COE. 

THE  CONCEPT  OF  AN  XML  BASED  DATA  EXCHANGE 

The  concept  of  developing  an  XML  based  data  exchange  is  not  a  new  concept.  The 
Aerospace  Industry  Association  has  always  had  an  interest  in  exploiting  computer  technology  to 
enhance  the  ability  of  aircraft  manufacturers  to  share  information  across  their  manufacturing 
processes.  Recently,  many  aircraft  industry  manufacturers  began  using  EXOSTAR  to  increase 
the  amount  of  business  they  conduct  over  the  Internet.  “EXOSTAR  in  Herndon,  Va.  is  an  e- 
business  service  provider  with  an  e-marketplace  for  the  aerospace  and  defense  industry.” 

The  EXOSTAR  marketplace  is  based  on  standard  XML  data  definitions  developed  and  agreed 
upon  within  a  consortium  of  aerospace  industry  manufacturers. 

Much  the  same  as  the  aircraft  industry,  the  automobile  manufacturing  industry  has 
developed  an  automobile  industry  specific  exchange  called  COVISINT.  These  exchanges  can 
“transform  disparate  supply  chain  systems  and  methodologies  among  different  buyers  and 
sellers  into  a  standardized  platform  that  streamlines  the  e-procurement  process.”^^  In  these  two 
cases  the  major  aircraft  and  automobile  industry  leaders  “set  the  rules  and  standards  that  their 
suppliers  must  follow.’^®  The  smaller  suppliers  must  follow  the  standards  and  map  their 
automated  systems  to  the  established  rules  of  those  exchanges  in  order  to  do  business  with  the 
buyers. 

If  industry  organizations  such  as  the  Aerospace  Industry  Association  and  the  American 
Automobile  Manufacturers  Association  can  work  together  to  develop  common  XML  based  data 
exchanges  to  allow  data  sharing  within  their  procurement  and  manufacturing  processes,  then 
the  Department  of  Defense  and  its  military  Services  could  develop  a  common  XML  based 
logistics  data  exchange  to  allow  data  sharing  across  the  Services’  logistical  support 
organizations.  The  development  of  extensible  Mark-up  Language  (XML)  technology  has 
provided  new  processes  for  sharing  information  across  various  information  technology 
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platforms.  Because  XML  technology  allows  different  systems  to  share  information  across  the 
Internet  via  a  data  exchange  without  building  Application  Program  Interfaces  (APIs),  the  data 
sharing  capabilities  can  be  expanded  to  include  additional  systems  or  changes  to  existing 
systems  without  making  changes  to  those  systems  that  are  currently  mapped  to  the  exchange. 

CURRENT  EB-XML  EFFORTS 

DLA  and  DISA  currently  share  oversight  of  the  Defense  EBusiness  exchange  (DEBX),  a 
relatively  new  XML  data  exchange  designed  to  provide  a  single  interface  with  commercial 
industry  and  DoD.  The  DEBX  exchange  automates  “procurement  and  delivery  of  goods  and 
services,  along  with  purchase  card  transactions,  travel  arrangements  and  electronic  fund 
transfers. With  the  establishment  of  the  DEBX  exchange,  some  groundwork  has  already 
been  accomplished  in  the  development  of  a  DoD  wide  logistics  exchange.  This  automated 
exchange  process  is  XML  based  and  could  be  extended  to  include  other  logistics  functions  and 
processes.  Additional  work  has  also  been  accomplished  through  DoD’s  Defense  Information 
Infrastructure  (Dll)  working  groups  with  the  development  of  XML  based  schemas  and  models  for 
processing  product  data  information  required  to  enable  electronic  requests  for  engineering 
support  and  electronic  engineering  change  proposals  (ECPs). 

One  of  the  first  XML  based  pilot  projects  recommended  by  the  Dll  working  group  was  the 
Product  Data  Mark-up  Language  (PDML)  project  to  automate  engineering  support  requests 
(ESRs)  that  were  managed  via  the  DLA  Form  339.  DLA  procures  all  consumable  items  for  all  of 
the  Services  and  must  identify  specific  product  data  required  to  support  the  Services’  weapon 
systems.  “Product  data  is  an  essential  component  of  many  procurement  actions.  In  Item  repair 
or  reprocurement  actions  where  product  data  is  required,  the  technical  data  package  must  be 
assembled  and  then  distributed  to  potential  vendors.’’^® 

During  the  process  of  assembling  a  technical  data  package,  DLA  may  require  support 
from  a  Service’s  engineering  department.  At  one  time,  requests  for  engineering  support  were 
submitted  via  hard  copy  forms  called  “DLA  Form  339.”  The  PDML  project  built  an  XML  based 
process  to  integrate  the  processing  of  the  electronic  Form  339  between  Defense  Supply  Center 
Richmond  (DSC-R)  and  the  following  three  Service  inventory  control  points:  the  Naval  Inventory 
Control  Point  (NAVICP),  Mech.,  PA;  the  U.S.  Army  Tank  Automotive  and  Armaments  Command 
(TACOM),  Warren,  Ml;  and  the  Marine  Corps  Logistics  Base  (MCLB),  Albany,  GA.  The  PDML 
project  leveraged  on-going  work  and  existing  work  to  automate  the  Form  339  process.  It 
demonstrated  how  an  XML  schema  could  be  used  to  enable  interoperability  between  several 
disparate  computer  systems  within  a  Web-based  environment. 
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The  second  project,  the  Joint  Engineering  Change  Management  Model  (JECMM)  project 
used  lessons  learned  from  the  PDML  project  to  push  this  type  of  technology  even  further  by 
developing  an  XML  based  model  of  the  data  and  processes  required  to  initiate,  process  and 
approve  an  engineering  change  proposal  (ECP)  across  commercial  and  various  DoD  computer 
systems.  The  strategy  of  the  JECMM  pilot  project  was  to  demonstrate  that  an  open,  standards- 
based,  Web-based  information  exchange  architecture  could  enable  a  near  “plug-and-play” 
environment  connecting  “commercial  off  the  shelf”  (COTS),  “government  off  the  shelf”  (GOTS) 
and  legacy  applications/systems  and  data  repositories  in  a  common  engineering  change 
management  (ECM)  process.  The  JECMM  pilot  project  was  built  around  a  community  of 
interest,  a  collection  of  DoD  organizations  that  had  a  need  to  share  product  information  within 
the  ECM  process.  The  JECMM  pilot  tested  the  ability  of  a  small  suite  of  XML  web-based 
technologies  to  achieve  interoperability  between  system  engineering  and  logistics  processes. 
With  joint  products  or  products  with  similarities  across  Military  Services,  sharing/exchanging 
information  digitally  between  participating  organizations  in  the  different  Services  and  DLA 
becomes  critical  to  getting  the  desired  product  improvements  to  the  user  faster. 

The  JECMM  pilot  project  specifically  addressed  the  Configuration  Management  (CM) 
challenge  of  managing  multiple  configurations  of  the  same  weapon  system  by  enabling  the 
tracking  of  a  great  number  of  configurations,  such  as  design  configuration,  pre-production 
configuration,  as-built,  as-maintained  and  as-modified.  CM  is  a  large  and  very  important 
process  for  managing  products,  such  as  DoD  weapon  systems,  over  their  life  cycle.  CM  is 
typically  divided  up  into  the  three  sub-process  areas:  Configuration  planning  and  management, 
Engineering  change  management  and  Configuration  status  accounting  and  audit. 

The  ECM  process  is  the  most  dynamic  part  of  the  CM  process  and  is  most  often  the  driver 
for  product  configuration  changes.  The  ECM  process  is  applicable  throughout  the  product  life 
cycle,  especially  since  it  is  often  the  case  that  engineering  change  proposals  need  to  be 
evaluated  against  earlier  baselines  that  may  include  “as  designed.”  “As  designed”  refers  to  the 
way  a  piece  of  equipment  was  designed  to  function  in  a  weapon  system  prior  to  any  engineering 
changes.  The  ECM  challenge  is  even  greater  for  joint  products  or  weapon  systems,  especially 
in  the  coordination  of  proposed  changes  and  the  exchange  of  information  related  to  the 
proposed  changes.  The  JECMM  pilot  project  explored  the  capability  of  a  proposed  open, 
standards-based  technology  to  provide  a  robust  XML  based  information  exchange  capability 
between  the  Services  and  DLA. 
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CONCLUSION 

One  of  the  common  problems  with  many  acquisition  programs  is  much  of  the  technical 
data  required  for  operating  and  maintaining  a  weapon  system  does  not  continue  to  flow  to  field 
offices  after  systems  are  fielded.  Therefore,  critical  operating  and  maintenance  information  may 
not  be  distributed  to  people  who  need  it.  Many  acquisition  programs  are  most  concerned  with 
getting  products  out  to  their  user  customer  base.  Although  technical  data  is  usually  available 
with  the  products,  it  can  be  out  of  date,  not  received  with  the  product,  or  if  it  is  received,  it  is  in 
hard  copy  format  or  an  electronic  format  that  is  not  easily  updated  or  transmitted  to  the  field  in  a 
timely  manner.  With  the  use  of  a  logistics  data  exchange,  product  information  could  be  made 
available  as  it  is  required  and  as  it  becomes  available.  Manufacturers  could  share  new  product 
information,  future  engineering  changes,  technical  document  updates  and  product  safety 
notices.  All  of  this  information  is  valuable  both  in  the  field  and  for  the  re-procurement, 
maintenance  and  repair  processes. 

Future  logistics  processes  must  provide  combatant  commanders  the  opportunity  to  act  on 
timely  information.  The  speed  and  operational  tempo  envisioned  for  future  combat  systems  will 
not  afford  future  logistics  systems  the  luxury  of  having  a  lot  of  time  to  mass  the  materials  in 
order  to  sustain  battlefield  operations.  Therefore  future  logistics  processes  will  need  to  work 
smarter  and  faster  with  much  less  mass  and  higher  velocities  of  material  in  order  to  get  the  right 
material,  at  the  right  place,  at  the  right  time.  Smarter  and  faster  logistics  systems  will  require  a 
higher  degree  of  interoperability  and  flexibility. 

As  demonstrated  by  the  many  projects  that  are  either  in  development  or  have  recently 
been  implemented,  the  use  of  XML  based  data  exchanges  can  be  a  powerful  tool  for  enabling 
integration  among  many  different  computer  systems.  To  date,  there  has  been  no  DoD  strategic 
plan  or  focus  to  coordinate  XML  development  efforts  and  existing  data  standards  in  order  to 
identify  a  common  logistics  data  exchange  across  the  DoD.  By  cross-referencing  and 
augmenting  the  existing  logistics  data  definitions  in  the  DISA  XML  registry  with  the  standard 
definitions  within  GCSS  and  other  joint  systems,  the  DoD  could  begin  managing  the  myriad  of 
logistics  data  definitions  and  begin  developing  a  standard  joint  logistics  data  exchange.  There 
are  many  challenges  that  must  be  overcome  in  order  to  move  the  DoD  to  a  joint  logistics  data 
exchange. 

First,  there  are  the  challenges  of  coming  to  a  common  understanding  across  the  Services 
of  what  standard  data  definitions  should  be  used  to  enable  each  system  to  appropriately 
understand  the  information  that  is  being  shared.  Much  of  this  work  has  already  been 
accomplished  in  one  form  or  another.  This  is  the  logical  data  and  process  modeling  aspect  of 
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using  and  sharing  data  based  on  its  intended  meaning.  To  overcome  this  challenge  a  DoD 
working  group  could  be  established  to  review  existing  standards  and  make  recommendations 
for  the  definitions  that  need  to  be  housed  in  the  joint  exchange. 

Second,  there  are  challenges  related  to  the  physical  connectivity  and  networking  of  the 
systems  involved  in  an  exchange.  The  development  of  connectivity  between  the  Services,  DLA 
and  commercial  entities  requires  negotiation  and  the  development  of  some  standards  to  allow 
passage  of  information  through  firewalls  and  gateways.  The  developers  must  determine  what 
message  transport  services,  adapters  and  integration  tools  to  use  and  what  business  process 
rules  will  be  used  to  govern  the  transporting  and  routing  of  information. 

The  physical  concerns  of  connecting  software  systems  in  a  global  environment  across  all 
of  the  Services  and  DLA  primarily  involve  the  software  protocols  and  tools  that  link  together  their 
various  applications  and  enable  them  to  exchange  messages.  These  protocols  and  tools  are 
the  system  adapters  and  transport  mechanisms  that  connect  legacy  software  to  the  data 
repositories  and  warehouses  that  contain  information  about  the  many  different  weapon  systems 
managed  by  the  DoD.  DISA  would  be  the  logical  choice  for  managing  physical  connectivity 
between  the  Services,  industry  vendors  and  a  joint  logistics  data  exchange,  since  it  has  the 
responsibility  of  maintaining  most  of  those  data  warehouses  and  repositories. 

In  contrast  to  the  physical  connectivity,  the  logical  data  concerns  involve  understanding 
what  the  data  in  one  military  Service  system  actually  means  in  that  system  and  how  it  relates  to 
each  of  the  other  DoD  systems  and  vendor  systems.  Addressing  these  semantic  concerns 
involves  discovering  how  information  is  used  differently  by  each  of  the  Service  systems  and  how 
that  information  maps  to  the  common  or  standard  view.  Currently,  most  semantic 
interoperability  issues  are  handled  by  either  a  common,  group  vocabulary  of  terms  such  as  EDI 
and/or  custom-coded,  point-to-point  bridges  that  translate  how  one  particular  vocabulary  is 
supposed  to  relate  to  the  group’s  vocabulary  or  another  Service’s  vocabulary. 

Further  logistic  system  integrations  could  include  integrating  the  standard  DoD  joint 
logistics  data  exchange  to  some  of  the  industry  trading  portals  such  as  EXOSTAR  and 
COVISINT.  This  would  require  negotiations  with  and  agreement  of  trading  portal  members. 

The  successful  development  of  common  data  exchanges  within  private  industries  provides 
ample  examples  for  the  DoD  to  emulate  and  verifies  that  this  type  of  development  effort  can 
provide  great  benefit  while  also  holding  down  the  cost  of  reengineering  existing  systems.  A 
standard  joint  logistics  data  exchange  within  the  Department  of  Defense  would  provide 
interoperability  among  existing  DoD  systems  and  industry  partners  while  allowing  the  DoD  to 
begin  moving  toward  the  incremental  development  of  standard  systems  and  processes. 
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Interoperability  is  cited  as  a  requirement  in  Joint  Vision  2020.  “Interoperability  is  the 
foundation  of  effective  joint,  multinational,  and  interagency  operations.”^®  A  standard  XML 
based  data  exchange  for  joint  logistics  information  would  not  only  support  this  requirement  but 
also  enable  collaboration  between  the  Services  and  their  industry  partners.  Existing  private 
industry  exchanges  have  already  proven  that  this  type  of  data  exchange  can  dramatically 
improve  interoperability.  The  DoD  has  already  invested  resources  to  standardize  data  for 
logistics  processes.  The  existing  DoD  standards  could  be  used  in  conjunction  with  industry 
standards  to  build  a  data  exchange  for  use  by  all  DoD  logistics  based  systems. 

All  changes  to  both  the  exchange  and  the  systems  supported  by  the  exchange  could  be 
developed  incrementally,  thus  spreading  the  cost  of  those  changes  across  time.  The  toughest 
problem  associated  with  building  a  joint  logistics  data  exchange  would  be  the  requirement  to 
identify  and  coordinate  all  existing  legacy  data  standards  and  systems  that  would  benefit  from 
the  development  effort.  A  common  data  exchange  could  eventually  lead  to  a  complete  standard 
system  for  processing  and  accessing  logistical  data  within  the  DoD. 

The  development  of  a  standard  joint  logistics  data  exchange  would  support  the  Dll  COE 
concept,  readiness,  integrated  logistics  and  logistics  interoperability.  The  exchange  would  also 
enhance  commanders’  logistics  decision-making  processes  and  enable  incremental  process 
changes  supporting  attainment  of  improved  logistics  performance.  A  standard  data  exchange 
would  allow  sharing  of  data  as  a  corporate  asset  across  DoD  and  promote  assimilation  of 
existing  and  future  logistics  applications. 

Integrating  related  processes,  tools,  systems  and  capabilities  into  a  broader  logistics 
process  exchange  will  improve  data  quality  by  reducing  the  need  to  reenter  data  because  the 
same  data  in  a  standard  format,  such  as  XML,  can  be  reused  by  many  applications.  Also  if  the 
primary  source  of  data  is  more  accessible,  such  as  over  the  Internet/Intranet,  then  there  is  less 
of  a  need  to  replicate  the  data  locally.  A  standard  XML  based  data  exchange  for  Joint  Logistics 
Information  would  allow  the  sharing  of  information  and  collaboration  between  buyers, 
maintainers,  designers,  vendors,  engineers  and  users.  It  could  be  developed  in  stages  and 
grow  from  past  and  current  standardization  efforts  and  provide  an  efficient  means  to  support  the 
war-fighter  in  the  field. 

RECOMMENDATIONS 

The  DoD  should  begin  development  of  a  standard  XML  based  data  exchange  for  logistics 
support.  The  DISA  XML  registry  should  be  used  as  the  DoD  data  standards  repository  for  all 
XML  components  describing  logistics  data.  The  standard  logistics  data  definitions  within  GCSS 
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should  be  used  as  a  starting  point  to  augment  existing  data  element  definitions  in  the  DISA  XML 
registry.  Application  interfaces  for  logistics  systems  currently  in  use  should  be  replaced  by 
mapping  them  to  the  new  standard  XML  based  data  exchange.  Additionally,  any  new  interfaces 
required  between  existing  systems  should  use  the  exchange  to  provide  information  between 
computer  systems  that  currently  do  not  have  that  capability.  Since  DISA  has  the  responsibility 
of  maintaining  many  of  DoD’s  data  warehouses  and  repositories  and  has  already  developed  the 
XML  registry  for  the  Dll  COE,  DISA  should  be  designated  to  manage  physical  connectivity 
between  the  Services,  industry  vendors  and  a  joint  logistics  data  exchange.  DISA  should 
determine  what  message  transport  services,  adapters  and  integration  tools  to  use  and  what 
business  process  rules  will  be  used  to  govern  the  transporting  and  routing  of  information.  The 
rules  should  be  consistent  with  current  Dll  COE  architecture  requirements  and  should  be 
published  for  use  by  DoD  developers. 

A  DoD  working  group  should  be  established  to  review  existing  standards  such  as  the  EDI 
standards,  GCSS  standardization  efforts,  DAASC  MILS  based  standards,  the  DISA  repository  of 
XML  components,  XML  based  EDI  components  and  any  other  existing  DoD  data  standards. 

The  working  group  should  identify  how  information  is  used  differently  by  each  of  the  Service 
systems  and  how  that  information  maps  to  the  common  or  standard  view.  After  the  review  the 
working  group  should  identify  and  make  recommendations  for  the  definitions  to  be  housed  in  a 
standard  joint  data  exchange.  The  working  group  should  negotiate  with  private  industry 
exchange  groups  such  as  EXOSTAR  and  COVISINT  to  become  trading  portal  partners  to 
integrate  the  standard  DoD  joint  logistics  data  exchange  to  some  of  the  industry  trading  portals. 
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